home *** CD-ROM | disk | FTP | other *** search
/ Meeting Pearls 4 / Meeting Pearls Vol. IV (1996)(GTI - Schatztruhe)[!].iso / Pearls / dev / ASM-Src / Chunky2Planar / pllb-c2p / Release.doc < prev    next >
Text File  |  1996-08-09  |  21KB  |  572 lines
  1.  
  2.  *=------------------------------------------------------------------------=*
  3.  
  4.  
  5.                    >> Precalc Linear lookup Blitter C2P <<
  6.  
  7.                              Version: 1.06
  8.  
  9.                         Released: 5th-08-1996
  10.  
  11.                    Written & Designed By:  Kevin Picone 
  12.  
  13.           (c) Copyright 1996 by Kevin Picone of Underware Design
  14.  
  15.                           All Rights Reserved.
  16.  
  17.  *=------------------------------------------------------------------------=*
  18.  
  19.          Contact: 'Kevin Picone' at Email: uwdesign@lin.cbl.com.au
  20.  
  21.  *=------------------------------------------------------------------------=*
  22.  
  23.  
  24.  Features: 
  25.  
  26.                   * Linear Chunky Frame Buffer
  27.  
  28.                   * Single,Double & Quad Pixel widths are supported
  29.  
  30.                   * Uses Normal (none resorted Pixels)
  31.  
  32.                   * 256/64/16 Colour Versions
  33.  
  34.                   * Various Specialized C2P methods.
  35.                  
  36.                           * Normal
  37.                           * Delta
  38.                           * Null Skip & Clear
  39.                           * Delta Null Skip & Clear      (NEW to V1.04)
  40.  
  41.                   * 16bit conversion with 32bit Writes to ChipRAM
  42.  
  43.   
  44.  Special Requirements:
  45.  
  46.                   * ECS/AGA Blitter for long blits.
  47.  
  48.                   * Fastram for Precalc buffer (from 512k -> 2meg ;)
  49.  
  50.                   * Normal Planar Screen  (NOT interleaved)
  51.  
  52.                   * No Screen modulo is allowed
  53.  
  54.  Disadvantages:
  55.  
  56.                   * Rather Hungry upon FASTRAM
  57.  
  58.                   * Extra ChipRAM demands 
  59.  
  60.                   * Uses the Blitter    
  61.                      
  62.                   * Provided Sources are *VERY* bulky 
  63.  
  64.                   * Can be cumbersome to initially add
  65.  
  66.                   * No 'C' support (sorry!)
  67.  
  68.  
  69.  *=------------------------------------------------------------------------=*
  70.  
  71.  
  72.  * Copyright:
  73.  ============
  74.  
  75.  The included source codes, intellectual properties, documentation and
  76.  their contained description of methods, remain the (c) copyright of
  77.  Kevin Picone 1996.
  78.  
  79.  I hereby grant permission for this code to be used freely in either  
  80.  P.D./Freeware/Shareware/commercial software releases or used as the basis
  81.  for a better C2P solution in PD/Freeware/Shareware/Commercial software
  82.  releases, with there being only one condition, that being that you *MUST*
  83.  credit me for my work.  ( a free copy of the software wouldn't hurt
  84.  either;) 
  85.  
  86.  This archive may be freely distributed via any means.
  87.   
  88.  
  89.  
  90.  * Disclaimer:
  91.  =============
  92.  
  93.  I in no way imply either directly or indirectly, that the described methods
  94.  or included source code(s) are the best (fastest) possible C2P solutions
  95.  in any/some/all cases or situations, they are provided as purely _optional_
  96.  methods to solve the c2p bottleneck.  
  97.  
  98.  
  99.  
  100.  * What is PLLB-C2P ?
  101.  ====================
  102.  
  103.  Precalc Linear Lookup Blitter - Chunky To Planar is actually a C2P
  104.  system and not just a few assorted routines.  The system (although it was
  105.  originally designed purely for my own use) _attempts_ to allow the
  106.  programmer too easily setup and support various bitplane depths, pixel
  107.  widths and conversion methods with relative ease.
  108.  
  109.  
  110.  
  111.  * What are 'Normal' 'Delta' & 'Nullskip' c2p routines ?
  112.  =======================================================
  113.  
  114.  Pllpc2p has built in support for various types of c2p conversion.  These
  115.  methods are 'Normal', 'Delta', 'NullSkip' & 'DeltaNullSkip'.  I've done
  116.  this for one rather obvious reason, as it's quite common that specific
  117.  rendering algorithms can have their performance enhanced by using
  118.  customized c2p solutions.  Hence, I've given you as many choices as I
  119.  possibly could, actually I've probably gone overboard, but who cares. ;)
  120.  
  121.  
  122.  * Normal       - This method is the simplest type of C2P possible, each
  123.                   frame it will convert the entire chunky frame buffer into
  124.                   planar.
  125.  
  126.                   Normal C2P is probably best used when your chunky frame
  127.                   buffer is constantly changing by say %80->%100.
  128.                    
  129.  
  130.  * Delta        - Delta c2p is a little more complex, it constantly takes
  131.                   two chunky frame buffers, the chunky frame just rendered
  132.                   and the last chunky frame rendered, and then compares
  133.                   them, looking for differences.  Each time a difference
  134.                   is found, it converts that group of 16 pixels into planar. 
  135.  
  136.                   Delta c2p can be very powerful, and not too mention
  137.                   quite fast in various situations. Personally, I'd recommend
  138.                   that you use it over 'normal' c2p, or at least do some
  139.                   performance tests yourself.
  140.  
  141.                   Those Familiar with Delta C2P algo's will notice that PLLB
  142.                   c2p allows for double buffering of your 'planar' image.
  143.                   i.e. you don't just render over the current visible
  144.                   frame. (So no ugly frame cuts.)
  145.  
  146.                   Moreover, Pllbc2p Delta routines, work in 16 pixel (or
  147.                   less, depends upon the pixel width) delta fields, for
  148.                   improved delta frequency and only shift data to ChipRAM
  149.                   when a difference is found.
  150.  
  151.  
  152.  * NullSkip     - Is a specialize C2P algorithm that scans for groups of
  153.                   NULL pixels (groups of pixel 0).  Each time it locates
  154.                   a NULL pixel group, it performs a quick clear operation
  155.                   to the planar buffer and then continues on, instead of
  156.                   passing the null (clear) pixels through the c2p process.
  157.  
  158.                   NullSkip C2P is probably best used, when you can be fairly
  159.                   sure that a large part of chunky frame buffer is going to
  160.                   be constantly blank/clear.
  161.  
  162.                   Nullskip also clears your chunky buffer as it goes.
  163.  
  164.  
  165.  * DeltaNUllSkip- Is just a logical extension to 'NUllSKIP', and NO it's
  166.                   not a combination of the 'DELTA' + 'NULLSKIP" Methods.
  167.                   It's actually a rather simple way to reduce the chipram
  168.                   access in the null skip algorithm.  Which is very useful
  169.                   on high end CPU's like the 060, 040, and even 40/50mhz
  170.                   030 systems.
  171.  
  172.                   It works via remembering if the present group of NULL
  173.                   pixels was cleared in the planar buffer during the last
  174.                   c2p sweep or not. If it was, then it doesn't write to chip
  175.                   at all, if not, it performs the clear and sets the delta
  176.                   tag for this group of pixels.  Hence, this reduces the
  177.                   amount of chipram access and provides a handy speed-up
  178.                   in the process.
  179.  
  180.                   DeltaNullSkip also clears out the chunky buffer while it
  181.                   processes it.
  182.  
  183.    
  184.             
  185.  
  186.  * I don't understand this Pixelwidth stuff ?
  187.  ============================================
  188.  
  189.  Pllbc2p, like most other C2p routines supports various pixel widths,
  190.  including 'Single', 'Double' and even 'Quad' pixel modes.
  191.  
  192.  In Double & Quad pixel mode, pllbc2p allows you to render a halved or
  193.  quarter sized (width) chunky image, that the c2p routine will automatically
  194.  blow it up to your selected planar screen width.  This can greatly improve
  195.  both your our algorithms performance and of course the c2p routines
  196.  performance.
  197.  
  198.  Pllbc2p doesn't automatically support various Pixel height, so you'll
  199.  have to set those up yourself.  I normally just use the copper to blur
  200.  the scan lines.
  201.  
  202.  
  203.  
  204.  * The Bizarre Method:
  205.  =====================
  206.  
  207.  The following method outline is based upon the 256 colour single pixel
  208.  width, other c2p modes may and do vary..
  209.  
  210.  
  211.  PLLB-C2P is a 16bit combination processor sweep / with lookup array and
  212.  Blitter resort algorithm, which was originally designed for 020/030 and
  213.  ECS/AGA systems, But it's also very useful on 040 & 060 processors.
  214.  
  215.  
  216.  The basic idea behind the algorithm is the usage of large Pre calculated
  217.  pixel combination tables.  These tables gives us the ability to directly
  218.  use the chunky pixels as pointers into the Pre calculated conversion
  219.  table(s).  The chunky lookup table(s), contain all the possible
  220.  combinations of two 8bit chunky pixels in their unrolled planar format.
  221.  (I.e. 8 bytes...)
  222.  
  223.  
  224.  Examples. (256colour Pixel width of 1)
  225.  
  226.                     (p=plane)    p0  p1  p2  p3  p4  p5  p6  p7
  227.  
  228.          Chunky Input $00,$0f = $01,$01,$01,$01,$00,$00,$00,$00
  229.          Chunky Input $0f,$00 = $02,$02,$02,$02,$00,$00,$00,$00
  230.          Chunky Input $01,$0f = $03,$01,$01,$01,$00,$00,$00,$00
  231.          Chunky Input $88,$55 = $01,$00,$01,$02,$01,$00,$01,$02
  232.          Chunky Input $ff,$0f = $03,$03,$03,$03,$02,$02,$02,$02
  233.  
  234.  
  235.  Obviously, with a little simple maths you'll quickly notices that this
  236.  means the lookup array for two 8bit chunky pixels ='s (256*256*8) = 512K ;) 
  237.  and can be as large as 2 megabytes, if available.
  238.  
  239.  Since the tables are unrolled into precalced groups of 8 bytes (2 longwords)
  240.  , the idea is too always MOVE/logical OR from these tables in longwords,
  241.  into our tempory data registers on the CPU..
  242.  
  243.  So to overview the conversion process of 16 chunky pixels into planar,
  244.  we've got the following simple routine.
  245.  
  246.  
  247.  Convert the first 8pixels, Pixels 0->7
  248.  
  249.  ; A0 = pointer to CHunky pixel buffer
  250.  
  251.  ; A5 = Base pointer to the Precalc comb's buffer
  252.  
  253.  ; Process 8 Chunky bits into planar
  254.  
  255.     clr.l d1        ; Clear out d1
  256.     move.l (a0)+,d0        ; Move Bytes ABCD from chunky buffer
  257.     move.w d0,d1        ; move bytes CD into d1
  258.     clr.w d0        ; AB-- clear low word of D0
  259.     swap d0            ; --AB exchange upper word for lower word
  260.  
  261.     lsl.l #3,d0        ; mult d0 * 8 (width of precalc buffer)
  262.  
  263.     move.l (a5,d0.l),d3    ; grab planes 1,2,3,4 for pixels AB
  264.     move.l 4(a5,d0.l),d4    ; grab planes 5,6,7,8 for Pixels AB
  265.  
  266.         lsl.l #2,d3    ; Shift PLanes 1,2,3,4 up 2 bits 
  267.         lsl.l #2,d4    ; sift planes 5,6,7,8 up 2 bits
  268.  
  269.     lsl.l #3,d1        ; mult by 8 (width of precalc Buff)
  270.     or.l (a5,d1.l),d3    ; or on planes 1,2,3,4 for pixels CD 
  271.     or.l 4(a5,d1.l),d4    ; or on planes 5,6,7,8 for pixels CD    
  272.  
  273.         lsl.l #2,d3    ; Shift PLanes 1,2,3,4 up 2 bits 
  274.         lsl.l #2,d4    ; sift planes 5,6,7,8 up 2 bits
  275.  
  276.        ;(first 4 pixels are processed at this point)
  277.  
  278.     clr.l d1        ; Clear out d1
  279.     move.l (a0)+,d0        ; Move pixels EFGH from chunky buffer intoD0
  280.     move.w d0,d1        ; move pixels GH into d1
  281.     clr.w d0        ; EF-- clear low word of D0
  282.     swap d0            ; --EF exchange upper word for lower word
  283.  
  284.     lsl.l #3,d0        ; mult EF * 8 (width of precalc buffer)
  285.  
  286.     or.l (a5,d0.l),d3    ; grab planes 1,2,3,4 for pixels EF
  287.     or.l 4(a5,d0.l),d4    ; grab planes 5,6,7,8 for Pixels EF
  288.  
  289.         lsl.l #2,d3    ; Shift PLanes 1,2,3,4 up 2 bits 
  290.         lsl.l #2,d4    ; sift planes 5,6,7,8 up 2 bits
  291.  
  292.     lsl.l #3,d1        ; mult GH by 8 (width of precalc Buff)
  293.  
  294.     or.l (a5,d1.l),d3    ; or on planes 1,2,3,4 for pixels GH 
  295.     or.l 4(a5,d1.l),d4    ; or on planes 5,6,7,8 for pixels GH    
  296.  
  297.  
  298.  d3 = a1b1c1d1e1f1g1h1a2b2c2d2e2f2g2h2a3b3c3d3e3f3g3h3a4b4c4d4e4f4g4h4
  299.  d4 = a5b5c5d5e5f5g5h5a6b6c6d6e6f6g6h6a7b7c7d7e7f7g7h7a8b8c8d8e8f8g8h8
  300.  
  301.  
  302.  Above, I mentioned that the precalc array could be as large as 2 megabytes
  303.  of FASTRAM, which is (unfortunately) true.  The reason for this is a
  304.  simple speedup which enables us to remove the two required 'lsl.l #2,d3'
  305.  & 'lsl.l #2,d4' instructions after each 'Move/logical or' completely
  306.  from the C2P loop.  The idea is to create 4 versions of the Precalced
  307.  Array with each one being already shifted into position.  Cumbersome
  308.  I know, but can make the routine(s) much faster....
  309.  
  310.  
  311.  Note:     The Pllb-C2p system handles all the possible buffer combinations
  312.  =====     all by it's  self.
  313.  
  314.  
  315.  Anyway, above also I stated that this is a 16bit routine, (which
  316.  is needed for the blitter resort pass) so after we've processed
  317.  the first 8 chunky pixels into planar,  we then repeat the process,
  318.  but this time storing the second converted 8 planes of pixels 8 to 15
  319.  into say registers d5,d6...
  320.  
  321.  
  322.  Now, all that's needed is to merge the planar data together, then move
  323.  it into the tempory CHIP buffer for the Blitter to resort/transfer to
  324.  our final screen...
  325.  
  326.  
  327.  ; a1 = output buffer in CHIPRAM
  328.  
  329.  ; d2 = $ff00ff00
  330.  
  331.  ; d3 = planes 1,2,3,4 pixels 0-7
  332.  ; d4 = planes 5,6,7,8 pixels 0-7
  333.  
  334.  ; d5 = planes 1,2,3,4 pixels 8-15
  335.  ; d6 = planes 5,6,7,8 pixels 8-15
  336.  
  337.  
  338.  ; resort the planar bytes into words 
  339.  
  340.  
  341.     move.l d3,d0    ; move Planes 1,2,3,4 to d0 (first 8 pixels_    
  342.     move.l d5,d1    ; move planes 1,2,3,4 to d1 (second 8 pixels)
  343.  
  344.     and.l d2,d0    ; mask with $ff00ff00  d0 ='s planes 1,-,3,-
  345.     and.l d2,d1    ; mask with $ff00ff00  d1 ='s planes 1,-,3,-
  346.                         ;                           (second 8 pixels)
  347.  
  348.     eor.l d0,d3    ; mask off planes 1,-,3,- from planes 1,2,3,4
  349.             ; d3 = -,2,-4
  350.     eor.l d1,d5    ; mask off planes 1,-,3,- from planes 1,2,3,4
  351.             ; d5 = -,2,-4 second 8 pixels
  352.  
  353.     lsr.l #8,d1    ; d1 = -,1,-,3 .. Second 8 pixels
  354.     or.l d1,d0    ; d0 = 1,1,3,3
  355.  
  356.     move.l d0,(a1)+        ; Dump out 32bits (16bits of planes 1 & 3)
  357.  
  358.     lsl.l #8,d3    ; d3 = 2,-,4,- 
  359.     or.l d5,d3    ; d3 = 2,2,4,4
  360.  
  361.     move.l d3,(a1)+        ; Dump out 32bits (16bits of planes 2 & 4)
  362.  
  363.  
  364.     (then repeat the process for Planes 4,5,6,7)
  365.  
  366.  
  367.  
  368.  One thing, you've probably already noticed, is that via this method your
  369.  able to write to CHIPRAM in Longwords without a great amount of fuss...
  370.  Plus, the routine(s) are small enought to fit nicely within the 68020's
  371.  small instruction cache, which helps a great deal.  In _theory_ pllbc2p
  372.  on an 28mhz 020's should be as fast if it was running on a 25mhz 030's,
  373.  but obviously various conditions could hinder this.
  374.  
  375.  
  376.  Unfortunately, we still need to use the blitter to move/resort the mixed
  377.  processed display (which is now in Chipram) from the Tempory Image buffer
  378.  to it's final resting place, the screen.  To avoid having too mess with the
  379.  blitter constantly the final screen(s) need to be defined as normal planar
  380.  and *NOT* interleaved, as this allows us to blit move an entire BitPLane
  381.  worth of Pixels, per each useage of the blitter.
  382.  
  383.  Hence, a simple hardware bashing routine to Move/Resort a single bitplane
  384.  from the tempory image buffer to the display screen, would look something
  385.  like this.
  386.  
  387.  
  388.  Bitter_Moveresort_TempImageBitplane_to_Display:    ; (NICE LABEL ;)
  389.      
  390.      lea.l $dff000,a6        
  391.  
  392.     jsr waitblitter            ; wait for Blitter ;)
  393.  
  394.     move.l #$09f00000,$40(a6)    ; setup blitter miniterms and chan's
  395.     move.l #$ffffffff,$44(a6)    ; init masks
  396.     move.l #((16-2)*$10000),$64(a6) ; setup source and dest modulo's
  397.  
  398.     lea.l BlitterTemp_ImageBuffer,a0
  399.     Move.l Display_buffer,a1
  400.  
  401.     add.l d0,a0    ; add on any source plane offset
  402.     add.l d1,a1    ; add on any dest plane offset
  403.  
  404.     move.l a0,$50(a6)    ; set blitter Chan A pointer to source buf 
  405.     move.l a1,$54(a6)    ; set blitter Chan D pointer to dest Buf
  406.     move.w #20*256,$5c(a6)    ; (20 words wide * 256 lines in Height
  407.     move.w #1,$5e(a6)    ; init width (1 word) and START!
  408.     rts
  409.  
  410.  
  411.  
  412.  The idea is to work out some way (depends on what your doing really) that
  413.  allows you to trigger the blitter and then just forget about it, which
  414.  could be via say, Async blits, Interrupts, copper or perhaps even another
  415.  Task or something.  Personally, I just found it simpler (in the Tmap
  416.  engine it was originally designed for) to check it's progress at
  417.  preselected times. ie. between mapping textures, objects, floors etc etc..
  418.  which added minimal (if any really) overhead, and seemed to work just
  419.  fine.. ;)..... lazy I know ;)
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  * What Memory Is needed ?:
  426.  ==========================
  427.  
  428.  Well this depends upon the type of game/demo or perhaps util your trying
  429.  to create.
  430.  
  431.  Since, i've included Normal, Delta, Nullskip & now Delta Nullskip versions
  432.  of each routine, well obviously your Buffer requirements will differ.
  433.  
  434.  
  435.  * NORMAL C2P
  436.  
  437.  In FASTRAM, all that you require (min) is too firstly allocate your
  438.  source CHUNKY PIXEL buffer and than the number of Precalc tables you wish
  439.  to use.. 1->4 ie. 512k->2meg ..
  440.  
  441.  In CHIPRAM, you'll need to allocate the tempory image buffer ie.
  442.  ((ScreenWidthInPixels/8) * ScreenHeight*bitplanes)='s size of Tempory
  443.  image buffer.  So if you were only using Two displays for double
  444.  buffering originally well now, you'll need an extra display for the
  445.  Tempory Image buffer.  (sorry)
  446.  
  447.  
  448.  * DELTA C2P
  449.  
  450.  The only different requirement for using the delta versions, is that
  451.  you'll need a second CHUNKY PIXEL buffer.  It should also be noted,
  452.  that you have to swap chunky pixel buffer pointers after each frame is
  453.  rendered, just as you would do normally for double/triple or even
  454.  Quad buffering purposes.
  455.  
  456.  
  457.  * NULL SKIP C2P
  458.  
  459.  The Nullskip versions have the same memory requirements as the Normal
  460.  C2P versions...
  461.  
  462.  
  463.  * DELTA NULLSKIP C2P
  464.  
  465.  Delta Nullskip has the same memory requirements as the Normal c2p version,
  466.  except it also needs a special 'delta' buffer so it can remember which
  467.  groups of null pixels it's cleared in the planar buffer.
  468.  
  469.  This buffer needs to be in FASTRAM and at least the size of your chunky
  470.  buffer divided by 4.  
  471.  
  472.  Ie. (ChunkyScreenwidth*ChunkyScreenheight)/4
  473.  
  474.  
  475.  
  476.  
  477.  PLEASE NOTE: Neither the Normal or Delta versions of the routine CLEAR
  478.               the source Chunky Frame Buffer.
  479.  
  480.  
  481.  
  482.  
  483.  * Linear Frame Buffer:
  484.  ======================
  485.  
  486.  After messing with various Tmapped & Gouraud Shaded engines (just like
  487.  everybody else) where the requirement of a chunky frame buffer for gfx is
  488.  high, the one rather obvious thing I found is that,  it's _normally_ much
  489.  better to save say a couple of cycles per chunky pixel, via rendering 
  490.  / copying across the linear buffer, than to save say a couple of cycles
  491.  in the C2P loop, particularly when your constantly rendering a full
  492.  frame buffer of pixels, where pixel (texture/gouraud) overlap (ie. polygons
  493.  that share the same screen space) is high.
  494.  
  495.  Pllb-c2p is probably quite unique, since it uses Precalc tables to preform
  496.  the actual bit shifting process, well we obtain a free linear buffer 
  497.  and we also achive slightly faster C2P in the process.
  498.  
  499.  
  500.  
  501.  * A possible C2P Hint for 'Wolf 3D' or 'Doom' texture mapped engines:
  502.  =====================================================================
  503.  
  504.  Without wanting to sound critical of *ANY* of the presently available
  505.  Tmap Engines, and having written a 'Blade Stone' ish engine myself,
  506.  (so I know just how hard the task actually is), the one thing I notice
  507.  is the lack of specialized C2P for when floor/Ceiling texture mapping isn't
  508.  present.  Personally, I consider this the ideal time for either a delta'd
  509.  C2P routine or a specialized NUll SKIP/CLEAR (you could make it use a
  510.  pattern) routine.  Via using the latter method, I was able to obtain
  511.  8->9fps refresh updates upon just a a1200/020 14mhz+fastram, with a
  512.  screen size of 320*256, 256colour, 1x*2y pixel res, while the engine
  513.  includes lightsources, Solid & See through Texture Mapped Walls & 2D
  514.  mapped objects.
  515.  
  516.  
  517.  Also, it becomes pretty obvious that for a Delta'd C2P routine to be all
  518.  that useful while Floor/Ceiling Mapping is present, that the artist
  519.  should  probably think more about making the floors & ceilings (and even
  520.  walls where possible) texture images a little less complex, which will
  521.  enchance preformance greatly.  It might also be a nice option for Full
  522.  or reduced detail floors & Ceilings, instead of turning them off
  523.  completely.
  524.  
  525.  
  526.  
  527.  * Why supply Quad Pixel width versions ?:
  528.  =========================================
  529.  
  530.  Well, what can I say, they give you an optional 'Copper' styled screen
  531.  resolution, but without the loss of 24bit colour. (not that it matters
  532.  too much at this res ;)  Perhaps they can be best used in effects like
  533.  'Fire' / 'Water' & 'Life' effects. 
  534.  
  535.  
  536.  
  537.  * Some Future Idea's:
  538.  =====================
  539.  
  540.  
  541.  * Auto 8bit to 6bit colour reduce/remapping.    (Still - Coming Soon ;)
  542.  
  543.  * Ham 8 with auto interpolation.       (Just a crazy idea at the moment ;)
  544.  
  545.  
  546.  
  547.  * That's it from me:
  548.  ====================
  549.  
  550.  Well, hopefully the enclosed routine(s) are of some use to you, or perhaps
  551.  they might inspire you to take this method further than I have, as this
  552.  is really only the initial working version(s) of PLLB-C2P, so I've *NO*
  553.  doubt there's any number of possible speed-ups just waiting to be found. 
  554.  
  555.  If you do bother too enhance any of the pllbc2p routines, well, I'd
  556.  appreciated it greatly if you'd let me know, so I can pass this
  557.  information to others in future releases of pllbc2p.
  558.  
  559.  
  560.  Cya,
  561.  
  562.  Kevin Picone
  563.  Underware Design
  564.  
  565.  
  566.  *=----------------------------------------------------------------------=*
  567.  
  568.                                T H E    E N D
  569.  
  570.  *=----------------------------------------------------------------------=*
  571.  
  572.